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Abstract 

Current  anonymous  communication  systems  make  a 
trade-off  between  weak  anonymity  among  many  nodes, 
via  onion  routing,  and  strong  anonymity  among  few 
nodes,  via  DC-nets.  We  develop  novel  techniques  in  Dis¬ 
sent,  a  practical  group  anonymity  system,  to  increase  by 
over  two  orders  of  magnitude  the  scalability  of  strong, 
traffic  analysis  resistant  approaches.  Dissent  derives  its 
scalability  from  a  client/server  architecture,  in  which 
many  unreliable  clients  depend  on  a  smaller  and  more 
robust,  but  administratively  decentralized,  set  of  servers. 
Clients  trust  only  that  at  least  one  server  in  the  set  is  hon¬ 
est,  but  need  not  know  or  choose  which  server  to  trust. 
Unlike  the  quadratic  costs  of  prior  peer-to-peer  DC-nets 
schemes.  Dissent’s  client/server  design  makes  communi¬ 
cation  and  processing  costs  linear  in  the  number  of  clients, 
and  hence  in  anonymity  set  size.  Further,  Dissent’s  servers 
can  unilaterally  ensure  progress,  even  if  clients  respond 
slowly  or  disconnect  at  arbitrary  times,  ensuring  robust¬ 
ness  against  client  churn,  tail  latencies,  and  DoS  attacks. 
On  DeterLab,  Dissent  scales  to  5,000  online  participants 
with  latencies  as  low  as  600  milliseconds  for  600-client 
groups.  An  anonymous  Web  browsing  application  also 
shows  that  Dissent’s  performance  suffices  for  interactive 
communication  within  smaller  local-area  groups. 

1  Introduction 

Anonymous  communication  is  a  fundamental  component 
of  democratic  culture  and  critical  to  freedom  of  speech  [5, 
40,56,57,59],  as  an  AAAS  conference  in  1997  concluded: 
“Anonymous  Communication  Should  Be  Re¬ 
garded  as  a  Strong  Human  Right;  In  the  United 
States  It  Is  Also  a  Constitutional  Right”  [56] 

The  Arab  Spring  underscored  the  importance  of  this 
right,  as  organizers  used  pseudonymous  Facebook  and 
Twitter  accounts  to  coordinate  protests  [46],  despite  vi¬ 
olating  those  sites’  Terms  of  Service  and  risking  ac¬ 
count  closure  [48].  Authoritarian  states  routinely  monitor 
and  censor  Internet  communication  [22] :  though  citizens 
may  risk  “slap-on-the-wrist”  punishments  like  blocking  or 
throttling  if  detected  to  be  using  anonymity  or  circumven¬ 


tion  tools  [24,25,50,62],  users  discussing  the  wrong  topic 
without  protecting  their  identity  risk  jail  or  worse. 

Even  in  countries  with  strong  free  speech  traditions, 
anonymity  can  protect  minority  groups  from  discrimina¬ 
tion  [53].  Increasingly  pervasive,  profit-motivated  track¬ 
ing  practices  [51]  have  made  communication  linkability 
a  widespread  privacy  concern  [30].  Finally,  anonymity 
plays  other  well-established  roles  in  modern  societies, 
such  as  in  voting  [2, 19,44]  and  auctions  [52]. 

Anonymous  relay  tools  such  as  Tor  [26]  offer  the 
strongest  practical  identity  protection  currently  available, 
but  exhibit  several  classes  of  weaknesses.  First,  relay  sys¬ 
tems  are  vulnerable  to  traffic  analysis  [6, 13,37,43,45].  A 
state-controlled  ISP,  for  example,  who  can  monitor  both 
a  user’s  “hrst-hop”  link  to  Tor  and  the  “last-hop”  link 
from  Tor  to  the  user’s  communication  partner,  can  cor¬ 
relate  packets  to  de-anonymize  flows  [43].  Second,  ac¬ 
tive  disruption  attacks  can  not  only  “deny  service”  but 
de-anonymize  flows  as  well  [6,  10].  Third,  independent 
of  the  underlying  anonymity  protocols  in  use,  widely- 
deployed  tools  often  fail  to  isolate  anonymous  from 
non-anonymous  communication  state  adequately,  causing 
application-layer  identity  leaks  via  third-party  browser 
plug-ins  for  example  [1,9, 17,27]. 

As  a  step  toward  stronger  anonymity  and  tracking  pro¬ 
tection  we  offer  Dissent,  a  practical  anonymous  group 
group  communication  system  resistant  to  traffic  analy¬ 
sis.  Dissent  builds  on  and  derives  its  strength  from  dining 
cryptographers  or  DC-nets  [14,  36]  and  verifiable  shuf¬ 
fles  [11,32,44].  Prior  systems  to  adopt  these  techniques, 
such  as  Herbivore  [35, 49]  and  an  earlier  version  of  Dis¬ 
sent  [20],  demonstrated  usability  for  anonymity  sets  only 
up  to  40-50  participants,  due  to  challenges  in  scaling  and 
handling  network  dynamics.  This  paper  improves  the  seal- 
ability  of  these  strong  anonymity  techniques  by  at  least 
two  orders  of  magnitude,  substantially  narrowing  the  gap 
compared  with  relaying  approaches  [18,21,26,38,42]. 

Dissent  derives  scalability  from  an  anytrust  architec¬ 
ture  [60].  A  Dissent  group  consists  of  a  potentially  large 
set  of  client  nodes  representing  users,  and  a  smaller  set  of 
servers,  facilitators  of  anonymous  communication.  Each 
client  trusts  that  at  least  any  one  server  will  behave  hon- 
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estly  and  not  collude  with  the  others  against  it,  but  the 
client  need  not  know  or  choose  which  server  to  trust. 
While  anytrust  is  not  a  new  idea,  Dissent  rethinks  DC-nets 
communication  [14]  around  this  model  by  sharing  secret 
“coins”  only  between  client/server  pairs  rather  than  be¬ 
tween  all  node  pairs,  yielding  a  novel,  practical  and  scal¬ 
able  system  design.  This  design  reduces  clients’  computa¬ 
tion  and  communication  burdens,  and  crucially  in  practi¬ 
cal  networks,  decouples  a  group’s  overall  communication 
performance  from  long  “tail  latencies”  caused  by  slow, 
abruptly  disconnected,  or  disruptive  clients. 

A  Dissent  prototype  demonstrates  usability  on  De- 
terLab  with  anonymity  sets  of  over  5,000  members — 
over  two  orders  of  magnitude  larger  than  anonymity  sets 
demonstrated  in  comparable  prior  systems  [20,35,49].  We 
expect  Dissent  to  scale  further  with  better  optimization. 

Although  this  paper’s  primary  contribution  is  to  show 
that  strong  anonymity  can  scale.  Dissent  also  addresses 
certain  disruption  and  information  leakage  vulnerabili¬ 
ties.  In  Tor  and  prior  DC-nets  schemes,  an  adversary  who 
controls  many  nodes  can  anonymously  disrupt  partially- 
compromised  circuits  to  increase  the  chance  of  com¬ 
plete  compromise  as  circuits  or  groups  re-form  [10]. 
Dissent  closes  this  vector  with  an  accusation  mecha¬ 
nism  adapted  to  its  anytrust  network  model,  enabling  a 
partially-compromised  group  to  identify  and  expel  disrup- 
tors  without  re-forming  from  scratch. 

In  local-area  settings  with  low  delay  and  ample 
bandwidth.  Dissent  can  be  used  for  anonymous  in¬ 
teractive  browsing  with  performance  comparable  to 
Tor.  In  this  context  Dissent  can  offer  a  strong  local- 
area  anonymity  set  complementing  Tor’s  larger-scale 
but  weaker  anonymity.  Dissent  addresses  an  impor¬ 
tant  class  of  anonymous  browsing  vulnerabilities,  due 
to  application-level  information  leaks  [1,  9,  27],  by 
confining  the  complete  browser  used  for  anonymous 
communication — including  plug-ins,  cookies,  and  other 
state — in  a  virtual  machine  (VM)  that  has  no  access  to 
non-anonymous  user  state,  and  which  has  network  access 
only  via  Dissent’s  anonymizing  protocols. 

Dissent  has  many  limitations  and  does  not  yet  ad¬ 
dress  other  weaknesses,  such  as  long-term  intersection  at¬ 
tacks  [39].  As  a  step  toward  stronger  practical  anonymity, 
however,  this  paper  makes  the  following  contributions: 

1.  An  existence  proof  that  traffic  analysis  resistant 
anonymity  is  feasible  among  thousands  of  participants. 

2.  A  client/server  design  for  DC-nets  communication  that 
tolerates  slow  or  abruptly  disconnecting  clients. 

3.  A  accusation  mechanism  offering  disruption  resistance 
in  large-scale,  low-latency  DC-nets  designs. 


4.  A  VM-based  browsing  architecture  enforcing  a  sepa¬ 
ration  between  anonymous  and  non-anonymous  state. 

5.  Experiments  demonstrating  Dissent’s  usability  in 
wide-area  messaging  applications,  local-area  interac¬ 
tive  anonymity  groups,  and  as  a  complement  to  Tor. 
Section  2  of  this  paper  describes  Dissent’s  goals  and 

how  they  relate  to  previous  work.  Section  3  presents  Dis¬ 
sent’s  architecture.  In  Section  4,  we  overview  our  pro¬ 
totype,  deployment  models,  and  experiences.  Section  5 
presents  the  results  of  our  experiments.  We  conclude  with 
a  summary  of  the  paper’s  accomplishments. 

2  Background  and  Related  Work 

This  section  outlines  the  state  of  the  art  in  both  practical 
anonymity  systems  and  theoretical  protocols,  with  a  focus 
on  the  key  security  weaknesses  that  Dissent  addresses. 

2.1  Practical  Anonymity  on  the  Internet 

Users  can  set  “Do  Not  Track”  flags  [30]  asking  web  sites 
not  to  track  them.  This  advisory  mechanisms  asks  the  fox 
to  guard  the  henhouse,  however,  relying  on  honest  behav¬ 
ior  from  the  web  site  and  all  network  intermediaries.  Even 
granted  the  force  of  law,  such  requests  may  be  ignored  by 
web  sites  in  “grey  markets”  or  foreign  jurisdictions,  just 
as  today’s  anti-spam  laws  are  ignored  and  circumvented. 

For  active  protection  against  tracking  or  identification, 
centralized  relay  services  such  as  Anonymizer  [4]  offer 
convenience  but  limited  security,  since  one  compromised 
server — or  one  subpoena — can  break  a  user’s  anonymity. 
Users  can  create  accounts  under  false  names  on  popular 
services  such  as  Facebook  and  Google-t,  but  risk  account 
loss  due  to  Terms  of  Service  violations — often  for  dubious 
reasons  [48] — and  may  still  be  traceable  by  IP  address. 

For  stronger  protection  without  a  single  point  of  fail¬ 
ure,  decentralized  relay  networks  [18,  21,  26,  38,  42] 
have  proven  practical  and  scalable.  Relaying  generally 
trades  convenience  against  security,  however,  with  some 
caveats  [54].  Mixminion  [21]  forwards  E-mail  through  a 
series  of  relays,  delaying  and  batching  messages  at  each 
hop  to  offer  some  traffic  analysis  protection.  Tor  [26],  in 
contrast,  consciously  sacrifices  traffic  analysis  protection 
to  achieve  low  latencies  for  interactive  Web  browsing. 

2.2  Anonymity  Sets:  Size  versus  Strength 

The  convenience  that  “weaker”  systems  such  as  Tor  of¬ 
fer  users  may  paradoxically  give  them  a  security  advan¬ 
tage  over  “stronger”  but  less  convenient  systems  such  as 
Mixminion,  because  convenience  attracts  more  users  and 
thus  yields  much  larger  effective  anonymity  sets  for  their 
users  to  hide  in.  Tor  only  offers  these  large  anonymity  sets, 
however,  provided  the  attacker  is  not  capable  of  traffic 
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analysis — likely  a  reasonable  assumption  when  Tor  was 
designed.  In  today’s  more  diverse  global  Internet,  how¬ 
ever,  the  adversary  from  whom  users  need  identity  pro¬ 
tection  may  often  be  a  national  ISP  controlled  by  an  au¬ 
thoritarian  state.  Such  an  adversary  realistically  can  mon¬ 
itor  and  “fingerprint”  the  traffic  patterns  of  users  and  web 
sites  en  masse,  completely  de-anonymizing  Tor  flows  that 
start  and  end  within  the  same  state.  More  recent  traffic 
analysis  attacks  [6, 13,37,45]  further  accentuate  this  class 
of  vulnerabilities.  Thus,  Tor  may  informally  be  viewed  as 
offering  a  potentially  large  but  weak  anonymity  set. 

Two  other  approaches  to  anonymity  theoretically  of¬ 
fer  security  even  against  traffic  analysis:  verifiable  shuf¬ 
fles  [11,32,44],  and  “dining  cryptographers”  or  DC- 
nets  [14,36,58].  Communication  and  computation  costs 
have  in  practice  limited  these  methods  to  small  anonymity 
sets,  however.  Herbivore  [35,49]  supports  mass  partici¬ 
pation  by  securely  dividing  large  networks  into  smaller 
DC-nets  groups,  but  guarantees  each  node  anonymity  only 
within  its  own  group,  showing  scalability  only  to  40-node 
groups.  The  first  version  of  Dissent  [20]  focused  on  ac¬ 
countability  rather  than  scalability,  combining  verifiable 
shuffles  with  DC-nets  to  prevent  anonymous  disruption, 
but  scaled  only  to  44-node  groups.  These  techniques  thus 
have  so  far  offered  strong  but  small  anonymity  sets. 

Today’s  anonymity  techniques  thus  present  even  well- 
informed  users  with  a  security  conundrum:  to  use  a  tool 
like  Tor  that  under  favorable  conditions  hides  them  among 
tens  of  thousands  of  others,  but  under  unfavorable  condi¬ 
tions  may  not  hide  them  at  all;  or  to  use  a  tool  that  can  of¬ 
fer  only  a  small  anonymity  set  but  with  higher  confidence. 
Dissent’s  goal  is  to  alleviate  this  conundrum. 

3  Dissent  Architecture 

This  section  first  summarizes  DC-nets,  then  details  how 
Dissent  achieves  scalability  and  resilience  to  slow  or  un¬ 
reliable  clients.  It  finally  outlines  how  Dissent  traces  dis¬ 
rupters  and  schedules  rounds,  and  current  limitations. 

3.1  DC-nets  Overview  and  Challenges 

In  classic  DC-nets  [14],  one  anonymous  sender  in  a  group 
wishes  to  share  a  message  with  fellow  group  members.  To 
exchange  a  1-bit  message,  every  member  shares  a  secret 
random  coin  with  each  of  the  other  —  1  members.  Every 
pair  together  first  flips  their  shared  coin,  agreeing  on  the 
outcome.  Then  each  member  individually  XORs  together 
the  values  of  all  the  coins  he  shares,  while  the  anonymous 
sender  additionally  XORs  in  his  1-bit  message,  to  pro¬ 
duce  the  member’s  ciphertext.  Finally,  all  members  broad¬ 
cast  their  ciphertexts  to  each  other.  Since  each  coin  is 
XORed  into  exactly  two  members’  ciphertexts,  all  shared 


coins  cancel,  revealing  the  anonymous  sender’s  message 
without  revealing  who  sent  it.  For  longer  messages,  the 
group  uses  multiple  coin  flips — in  practice,  cryptographic 
pseudo-random  number  generators  (PRNGs)  seeded  by 
pairwise  shared  secrets. 

Practical  implementations  of  this  conceptually  simple 
design  face  four  key  challenges:  scheduling,  disruption, 
scalability,  and  network  churn.  First,  since  DC-nets  yield 
an  Ethernet-like  broadcast  channel,  in  which  only  one 
member  can  transmit  anonymously  in  each  bit-time  with¬ 
out  colliding  and  yielding  garbled  output,  an  arbitration 
or  scheduling  mechanism  is  needed.  Second,  any  misbe¬ 
having  member  can  anonymously  disrupt  or  “jam”  the 
channel  simply  by  transmitting  random  bits  all  the  time. 
Dissent  builds  on  and  extends  several  prior  approaches  to 
address  these  challenges  [20, 36, 58]. 

The  third  challenge  directly  limits  scalability.  Every 
member  normally  shares  coins  (or  keys)  with  every  other 
member,  so  each  node  must  compute  and  combine  0{N) 
coins  for  every  bit  of  shared  channel  bandwidth.  Comput¬ 
ing  ciphertexts  via  modular  arithmetic  instead  of  XORed 
bits  [36]  can  address  this  issue  asymptotically,  but  at  a 
large  constant-factor  cost.  Communication  cost  can  also 
limit  scalability  if  every  node  broadcasts  its  ciphertext  to 
every  other.  In  Herbivore  [35,49]  a  single  node  collects 
and  combines  ciphertexts  for  efficiency,  but  this  leader¬ 
centric  design  offers  no  reliable  way  to  identify  anony¬ 
mous  disrupters  without  re-forming  the  group,  leaving 
groups  vulnerable  to  DoS  attacks  against  anonymity  [10]. 

The  fourth  challenge,  network  churn,  indirectly  lim¬ 
its  scalability  in  practice.  As  each  member  shares  a  coin 
with  every  other,  a  round’s  output  is  indecipherable  un¬ 
til  all  members  submit  their  ciphertexts.  Thus,  one  slow 
member  delays  the  entire  group’s  progress.  If  any  mem¬ 
ber  disconnects  during  a  round,  all  other  members  must 
recompute  and  rebroadcast  their  ciphertexts  anew.  Beyond 
“normal-case”  churn,  an  adversary  who  controls  /  group 
members  can  take  them  offline  one  one  at  a  time  to  force 
a  communication  round  to  timeout  and  restart  /  times  in 
succession.  Threshold  cryptography  can  address  this  issue 
in  non-interactive  scenarios  [36],  but  may  be  too  heavy¬ 
weight  for  interactive  communication. 

3.2  Design  and  Deployment  Assumptions 

Dissent  assumes  a  cloud-like  multi-provider  deployment 
model  illustrated  in  Figure  1,  similar  to  the  model  as¬ 
sumed  in  COR  [38].  A  Dissent  group  consists  of  a  pos¬ 
sibly  large  number  of  client  nodes  representing  individ¬ 
ual  users  desiring  anonymity  within  the  group,  supported 
by  a  small  number  of  reliable  and  well-provisioned  cloud 
of  servers.  We  assume  each  server  is  run  by  a  respected, 
technically  competent,  and  administratively  independent 
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Figure  1 :  Dissent’s  multi-provider  anytrust  cloud  model 

anonymity  service  provider.  We  envision  several  commer¬ 
cial  or  non-profit  organizations  each  deploying  a  cluster  of 
Dissent  servers  to  support  groups,  as  either  a  for-profit  or 
donation-funded  community  service. 

For  anonymity  and  other  security  properties  Dissent  re¬ 
lies  on  an  anytrust  assumption  [60].  Clients  need  not  rely 
on  all  or  even  particular  providers  or  their  servers  being 
honest.  Instead,  each  client  trusts  only  that  there  exists  at 
least  one  provider — any  provider — who  is  honest,  tech¬ 
nically  competent,  and  uncompromised.  Clients  need  not 
know  or  guess  which  provider’s  server  is  the  most  trust¬ 
worthy.  Later  sections  detail  how  Dissent’s  design  relies 
on  this  assumption  to  achieve  scalability. 

This  paper  focuses  on  the  operation  of  a  single  group — 
which  forms  an  anonymity  set  from  a  user’s  perspective — 
and  leaves  out  of  scope  most  details  of  how  groups  are 
formed  or  subsequently  administered,  how  providers  de¬ 
ploy  their  services  or  scale  to  support  many  groups,  etc. 
As  a  simple  group  formation  mechanism  we  have  pro¬ 
totyped,  an  individual  creates  a  file  containing  a  list  of 
public  keys — one  for  each  server  (provider)  and  one  for 
each  client  (group  member) — then  distributes  this  group 
definition  file  to  the  clients  and  servers.  A  cryptographic 
hash  of  this  group  definition  file  thereafter  serves  as  a 
self-certifying  identifier  for  the  group  [31],  avoiding  mem¬ 
bership  consensus  and  PKI  issues  at  the  cost  of  making 
the  group’s  composition  static.  The  group  formation  tech¬ 
niques  explored  in  Herbivore  [35,49]  could  offer  comple¬ 
mentary  methods  of  forming  Dissent  groups  dynamically. 

3.3  Dissent  Protocol  Outline 

To  initiate  communication,  a  group’s  servers  periodically 
run  a  scheduling  process  described  later  in  Section  3.10. 
This  process  yields  a  list  of  pseudonym  keypairs,  one  for 
each  participating  client.  All  nodes  know  and  agree  on  the 
list  of  public  keys  and  their  order,  and  each  client  knows 
the  private  key  for  its  slot  in  the  DC-net  defined  by  fhe 
ordered  list  of  pseudonym  keypairs,  but  neither  clients 
nor  servers  know  which  clients  hold  which  other  slots. 
This  list  schedules  subsequent  DC-nets  rounds  as  shown 
in  Figure  2,  and  enables  the  protocol  to  offer  accountabil¬ 
ity  as  described  later  in  Section  3.9. 
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DC-net  exchanges. 
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Figure  2;  DC-nets  scheduling  via  a  verifiable  shuffle 

After  setup,  group  members  commence  a  continuous 
series  of  rounds.  Each  round  allows  the  owner  of  each 
slot  to  transmit  one  or  more  bits  anonymously,  as  defined 
by  fhe  schedule  and  information  from  prior  rounds.  Dur¬ 
ing  a  round,  each  client  first  generates  M  pseudo-random 
strings,  each  based  on  a  secret  key  he  shares  with  each 
of  the  M  servers,  and  XORs  these  strings  together.  To 
send  a  message,  the  client  additionally  XORs  his  clear¬ 
text  message  into  the  bit  positions  corresponding  to  his 
anonymous  transmission  slot.  The  client  then  transmits 
his  ciphertexts  to  one  or  more  servers,  then  waits. 

The  servers  collect  as  many  client  ciphertexts  as  possi¬ 
ble  within  a  time  window.  At  the  end  of  this  window,  the 
servers  exchange  with  each  other  the  list  of  clients  whose 
ciphertexts  they  have  received.  Each  server  then  computes 
one  pseudo-random  string  for  each  client  that  submitted  a 
ciphertext,  using  the  secret  shared  with  that  client.  The 
server  XORs  these  strings,  together  with  with  the  client 
ciphertexts  the  server  received,  to  form  the  server’s  ci¬ 
phertext  (Eigure  3).  The  servers  then  distribute  their  ci¬ 
phertexts  among  themselves.  Upon  collecting  all  server 
ciphertexts,  each  server  XORs  them  to  reveal  the  clients’ 
cleartexts,  and  distributes  the  cleartexts  to  the  clients  con¬ 
nected  to  them,  completing  one  DC-net  round.  Successive 
DC-net  rounds  ensue. 

The  rest  of  this  section  describes  Dissent’s  client  and 
server  protocols,  summarized  in  Algorithms  1  and  2,  re¬ 
spectively,  and  In  Eigure  4.  All  network  messages  are 
signed  to  ensure  integrity  and  accountability,  but  we  omit 
these  signatures  to  simplify  presentation. 

3.4  Secret  Sharing  in  the  Anytrust  Model 

The  key  to  Dissent’s  scalability  and  resilience  to  churn  is 
its  client/server  secret-sharing  graph.  Unlike  the  “all-to- 
all”  secret-sharing  graph  in  most  DC-nets  designs,  Dissent 
shares  secrets  only  between  all  client/server  pairs. 

As  formalized  by  Chaum  [14],  the  anonymity  set  an 
honest  node  obtains  via  DC-nets  consists  of  the  node’s 
connected  component  in  the  secret-sharing  graph,  after 
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Figure  3:  Dissent  round  structure.  Each  client-server  pair 
shares  a  secret  pseudo-random  string  Sij.  Client  D  anony¬ 
mously  transmits  a  message  in  slot  1  and  client  A  anony¬ 
mously  transmits  a  message  in  slot  3.  Servers  do  not  XOR 
in  the  strings  for  offline  client  C. 

removing  dishonest  nodes  and  their  incident  edges  from 
the  graph.  A  sparser  secret-sharing  graph  thus  reduces  a 
node’s  anonymity,  compared  with  the  ideal  anonymity  set 
consisting  of  all  honest  nodes,  if  and  only  if  the  dishonest 
nodes  partition  the  honest  nodes  into  multiple  connected 
components.  Because  each  Dissent  client  shares  a  secret 
with  each  server,  the  honest  nodes  remain  connected — 
yielding  an  ideal  anonymity  set — if  and  only  if  there  is 
at  least  one  honest  server.  This  is  precisely  what  Dis¬ 
sent’s  anytrust  model  assumes.  The  downside  is  that  if  all 
servers  maliciously  collude,  clients  obtain  no  anonymity. 

A  direct  benefit  of  Dissent’s  client/server  secret-sharing 
is  that  clients  enjoy  a  lighter  computational  load  dur¬ 
ing  exchanges.  Each  client  shares  secrets  with  only  the 
M  N  servers,  thus  clients  need  only  compute  M 
pseudo-random  bits  for  each  effective  bit  of  DC-net  chan¬ 
nel  bandwidth.  Each  of  the  servers  must  compute  N 
pseudo-random  bits  per  cleartext  bit,  as  in  traditional  DC- 
nets,  but  these  computations  are  parallelizable,  and  Dis¬ 
sent  assumes  that  the  servers  are  provisioned  with  enough 
computing  capacity  to  handle  this  load.  Just  as  important 
in  practice,  however,  are  the  model’s  indirect  benefits  to 
network  communication  and  resiliency,  detailed  next. 

3.5  Optimizing  Network  Communication 

Dissent  leverages  its  client/server  architecture  to  reduce 
network  communication  overhead.  In  conventional  DC- 


Algorithm  1  Dissent  Client  DC-net  Protocol 

Scheduling:  Each  client  i  creates  a  fresh  secret 
pseudonym  key,  then  encrypts  and  submits  it  to 
a  key-shuffle  protocol,  which  permutes  and  decrypts 
all  clients’  keys,  giving  client  i  a  secret  permutation 
slot  7r(i)  unknown  to  all  other  nodes.  A  well-known 
scheduling  function  S{r,TT{i),  H)  determines  the  set 
of  bit-positions  client  i  owns  in  each  subsequent  DC- 
nets  round  r,  after  a  history  H  of  prior  round  outputs. 

Submission:  Each  client  i  forms  a  cleartext  message 
rrii  containing  arbitrary  data  in  the  bit-positions  i  owns 
according  to  S{r,  7r(i),  H),  and  zero  elsewhere.  Erom 
secrets  that  client  i  shares  with  each  server  j,  i 
computes  pseudo-random  strings  =  PRNG(iTij). 
Client  i  then  XORs  these  strings  with  message  rrii  to 
produce  ciphertext  Ci  =  m  ©  c^i  ©  •  •  •  ©  CiM,  which  i 
signs  and  transmits  to  one  or  more  servers. 

3.  Output:  Each  client  i  waits  for  a  message  from  any 
server  containing  round  r’s  cleartext  output  signed  by 
all  servers:  (r,  m,  sig).  Client  i  verifies  all  servers’  sig¬ 
natures,  extracts  the  messages  in  all  slots,  then  pro¬ 
ceeds  to  round  r  +  1  by  repeating  from  step  2. 

nets,  all  nodes  broadcast  messages  to  all  other  nodes.  Dis¬ 
sent  reduces  the  number  of  communication  channels  by  a 
factor  of  N  by  organizing  clients  and  servers  into  a  two- 
level  hierarchy.  Clients  communicate  with  only  a  single 
server,  and  servers  communicate  with  all  other  servers. 

This  optimization  does  not  make  a  client’s  anonymity 
dependent  on  the  particular  server  it  chooses  to  con¬ 
nect  to,  because  anonymity  depends  on  the  secret-sharing 
graph  described  above  and  not  on  physical  communi¬ 
cation  topology.  Since  each  client  shares  a  secret  with 
all  servers,  even  if  a  client’s  directly  upstream  server  is 
malicious,  that  server  cannot  decode  the  client’s  anony¬ 
mous  transmissions  except  with  the  cooperation  of  all 
the  servers,  including  the  honest  one  we  assume  exists. 
A  server  can  DoS-attack  an  attached  client  by  persis¬ 
tently  dropping  its  submitted  ciphertexts,  but  the  client 
will  recognize  such  an  attack  from  the  absence  of  its  dear- 
texts  in  the  group’s  output — which  all  servers  must  sign — 
signaling  the  client  to  switch  to  a  different  server. 

To  reduce  communication  costs  further,  servers  lo¬ 
cally  combine  their  pseudo-random  strings  with  their 
clients’  ciphertexts.  Servers  thus  avoid  forwarding  indi¬ 
vidual  client  ciphertexts  to  other  servers,  reducing  total 
communication  complexity  from  O(iV^)  to  0{N  +  M^) 
when  M  N .  Related  optimizations  reduce  the  num¬ 
ber  of  signature  verifications  a  client  performs  from  0{N) 


Client  B 

^B,X  ®  '^B,Y 

QfewcC 

Offline 

Client  D 

^D,X  ®  '^D.Y 

e 

Server  X 

Sa,x®Sb,x®M®So,x 

Server  Y 

•^A,Y  ®  ^B,Y  ®^^  ®  ^D,Y 

I 


msg  1 


msg  3 


5 


Algorithm  2  Dissent  Server  DC-net  Protocol 

1.  Submission:  In  each  round  r,  each  server  j  collects 
ciphertexts  from  some  clients  i,  until  all  of  j’s 
directly-connected  clients  have  responded  or  the  round 
closure  deadline  has  passed. 

2.  Inventory:  Server  j  forms  a  list  Ij  of  client  identities 
from  whom  j  has  received  ciphertexts  by  the  deadline, 
then  broadcasts  this  list  to  the  other  servers. 

3.  Commitment:  Given  all  servers’  vectors  Ij,  the 
servers  deterministically  trim  redundant  entries  for 
clients  who  submitted  ciphertexts  to  multiple  servers, 
yielding  new  lists  I'j,  then  form  a  composite  client  list 
I  =  IJ^  I'j.  If  the  round  r  participation  count  pr  =  |/| 
is  below  a  policy-defined  fraction  a  of  the  previous 
round’s  participation  count  pj._i,  the  servers  return  to 
step  1  and  wait  for  more  clients  to  submit  ciphertexts. 

Otherwise  each  server  j  computes  pseudo-random 
strings  =  PRNG(Ary)  from  the  shared  secrets  K^j 
of  clients  i  €  I,  and  XORs  these  strings  with  the  client 
ciphertexts  j  received  directly,  forming  server  cipher- 
text  Sy)©(0iei'  Cij).  Server  j  computes 

a  commit  Cj  =  HASH(sj)  and  sends  Cj  to  all  servers. 

4.  Combining:  Upon  receiving  all  other  servers’  commit, 
server  j  shares  sj  with  the  other  servers. 

5.  Certification:  The  servers  verify  Cj  =  HASH(sj)  for 
all  j,  and  form  cleartext  output  ifi  =  0^  sj.  Each 
server  j  signs  m,  and  sends  its  sigj  to  all  servers. 

6.  Output:  Servers  collect  all  signatures  sigj  into  sig, 
then  distribute  (r,  rn,  sig)  to  directly  attached  clients. 

to  0{M)  and  the  number  of  messages  clients  must  parse 
from  0{N)  to  0(1)  (see  Algorithm  1,  steps  2,  and  3). 

3.6  Tolerating  Network  Churn 

More  important  than  reducing  the  computational  load  on 
clients,  Dissent’s  client/server  secret-sharing  graph  en¬ 
ables  the  servers  to  collaborate  to  reduce  the  group’s  vul¬ 
nerability  to  client  disconnection  and  churn,  as  well  as 
deliberate  DoS  attacks  by  malicious  clients.  In  conven¬ 
tional  online  DC-nets,  if  any  member  goes  offline,  all 
other  members  must  recompute  and  resend  new  cipher- 
texts,  omitting  the  PRNG  stream  they  shared  with  the 
failed  member.  The  chance  that  a  given  round  will  have 
to  be  “re-run”  in  this  way  increases  dramatically  as  group 
size  and  client  churn  increase. 

Since  Dissent  clients  share  secrets  only  with  the  servers 
and  not  with  other  clients,  a  client’s  ciphertext  is  indepen¬ 
dent  of  the  online  status  of  other  clients.  The  servers  can 
therefore  complete  a  messaging  round  even  if  some  clients 


Client  Server  j  All  Servers 


Figure  4:  Dissent  DC-net  protocol. 

disconnect  at  arbitrary  points  during  the  round,  or  other¬ 
wise  fail  to  deliver  their  ciphertexts  before  a  deadline.  The 
servers  first  collect  those  client  ciphertexts  that  arrive  in 
time,  then  agree  among  each  other  on  the  complete  set  of 
client  ciphertexts  available  (the  union  of  all  servers’  client 
ciphertext  sets),  and  finally  XOR  these  client  ciphertexts 
with  the  pseudo-random  strings  each  server  shares  with 
those  clients  to  form  the  servers’  ciphertexts.  Thus,  client 
delays  or  disconnections  never  require  servers  to  inter¬ 
act  with  clients  iteratively  within  the  same  round,  as  they 
would  in  standard  DC-nets  to  obtain  revised  ciphertexts. 

3.7  Participation  and  Anonymity  Metrics 

To  ensure  “strength  in  numbers,”  users  may  wish  to  send 
anonymous  messages  only  when  at  least  some  number  of 
other  group  members  are  online  and  participating.  Since 
the  servers  know  the  set  of  clients  who  are  online  and 
successfully  deliver  ciphertexts  each  round,  the  servers 
publish  a  participation  count  for  each  round.  A  user  who 
judges  this  count  to  be  too  low  can  continue  to  participate 
passively  in  the  group  but  send  only  an  empty  (“null”) 
message  in  each  round  until  participation  increases. 

Servers  can  publish  participation  counts  only  for  past 
rounds,  but  clients  can  come  and  go  at  any  time.  A  client 
thus  might  decide  to  send  a  message  on  the  basis  of  one 
round’s  high  participation  count,  and  submit  a  sensitive 
message  in  the  next  round,  only  to  discover  after  the  round 
completes  that  far  fewer  clients  remained  online  or  deliv¬ 
ered  their  ciphertexts  in  time.  A  powerful  adversary  might 
even  start  a  DoS  attack  against  many  honest  clients  just  as 
a  sensitive  anonymous  posting  is  anticipated,  in  hopes  of 
isolating  and  exposing  the  poster  this  way. 

To  address  such  risks,  if  the  last  round’s  participation 
count  was  P,  the  servers  will  not  complete  the  next  round 
until  at  least  aP  clients  submit  ciphertexts,  where  0  < 
Of  <  1  is  a  policy  constant  defined  at  group  creation  time. 
If  fewer  than  aP  clients  submit  ciphertexts  by  the  round’s 
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deadline,  the  servers  keep  waiting  nntil  at  least  aP  clients 
show  up,  or  until  a  much  longer  hard  timeout  occurs.  On 
a  hard  timeout,  the  servers  discard  all  clients’  ciphertexts, 
report  the  round  as  failed,  and  publish  a  new  participation 
count  on  whose  basis  the  clients  make  fresh  decisions  for 
the  next  round.  The  fraction  a  thus  limits  the  rate  at  which 
participation  may  decrease  unexpectedly  round-to-round. 

While  Dissent  can  guarantee  users  that  a  sensitive  mes¬ 
sage  will  be  posted  only  when  participation  is  at  some 
threshold  level,  participation  count  unfortunately  offers 
only  an  estimate  of  anonymity  set  size.  If  some  partici¬ 
pants  are  dishonestly  colluding  with  the  adversary,  a  client 
is  anonymous  only  among  the  set  of  honest  participants. 
A  group’s  risk  of  infiltration  of  course  depends  on  how  it 
is  formed  and  managed.  In  our  current  approach  where 
a  group  is  defined  by  a  static  list  of  public  keys  (Sec¬ 
tion  3.2),  the  dishonest  members  are  those  whose  pub¬ 
lic  keys  the  adversary  manages  to  persuade  the  group 
creator  to  include  in  the  list  at  definition  time,  plus  any 
formerly-honest  members  who  the  adversary  might  com¬ 
promise  after  group  formation.  Since  users  cannot  ulti¬ 
mately  know  how  many  of  their  peers  may  be  “spies,”  es¬ 
timating  anonymity  necessarily  remains  subjective. 

3.8  Eliminating  Empty  Slot  Overhead 

In  typical  blogging  or  chat  applications  we  expect  many 
clients  to  be  silent  much  of  the  time,  sending  null  mes¬ 
sages  in  most  rounds  and  real  messages  only  occasion¬ 
ally.  To  optimize  this  common  case.  Dissent’s  scheduling 
scheme  gives  each  client  two  slots:  a  one-bit  request  slot 
and  a  variable-length  message  slot.  Initially  the  message 
slot  is  closed,  with  length  0.  When  a  client  sets  its  request 
bit  in  round  r,  its  message  slot  opens  to  a  fixed  size  in 
round  r  -f  1.  The  message  slot  includes  a  length  field,  with 
which  the  client  can  adjust  the  slot’s  length  in  subsequent 
rounds:  to  send  a  larger  message  efficiently  in  round  r  +  2, 
for  example,  or  to  close  its  message  slot  back  to  length  0. 

A  dishonest  member  could  DoS  attack  another  client  by 
guessing  when  the  victim  will  transmit  and  sending  a  1  in 
the  victim’s  request  slot,  cancelling  the  victim’s  open  re¬ 
quest.  To  address  such  attacks,  a  client  first  sets  its  request 
bit  unconditionally,  but  if  its  slot  fails  to  open,  the  client 
randomizes  its  request  bit  in  subsequent  rounds,  ensuring 
success  after  t  +  1  rounds  with  probability  1  —  (5)*. 

3.9  The  Accusation  Process 

Dishonest  members  can  disrupt  DC-nets  in  general  by 
XORing  non-zero  bits  into  other  members’  slots,  cor¬ 
rupting  the  victim’s  cleartext.  Earlier  approaches  to  this 
challenge  used  complex  trap  protocols  [58],  expensive 
pairing-based  cryptography  [36],  or  required  a  costly 
shuffle  before  every  DC-nets  round  [20].  Herbivore  [35] 


mitigates  the  risk  of  disruption  by  limiting  clique  size  and 
the  rate  at  which  disrupters  can  join  them,  at  the  cost  of 
small  anonymity  sets  and  potentially  increased  vulnera¬ 
bility  when  disrupters  are  common  [10]. 

Dissent  introduces  a  new  accusation  scheme  that  adds 
little  overhead  in  the  absence  of  disrupters,  but  enables 
the  servers  to  identify  and  expel  a  persistent  disrupter 
quickly  with  high  probability.  The  overall  scheme  oper¬ 
ates  in  three  stages.  First,  the  victim  of  a  disruption  must 
find  a  witness  bit  in  some  round’s  DC-net  output,  which 
we  define  as  a  bit  that  was  0  in  the  victim’s  cleartext, 
but  which  the  disrupter  flipped  to  a  1.  Second,  the  victim 
anonymously  broadcasts  an  accusation,  a  message  signed 
with  the  victim’s  pseudonym  key  identifying  the  witness 
bit.  Finally,  the  servers  publish  all  PRNG  outputs  that  con¬ 
tributed  to  the  client  and  server  ciphertexts  at  the  witness 
bit  position,  using  them  to  trace  the  client  or  server  that 
XORed  an  unmatched  1  bit  into  this  position.  The  signed 
accusation  attests  that  the  traced  node  must  be  a  disruptor. 

The  first  challenge  is  ensuring  that  a  disruption  victim 
can  find  a  witness  bit.  If  a  disruptor  could  predict  the  vic¬ 
tim’s  cleartext  output — or  discover  it  from  other  honest 
nodes’  ciphertexts  before  computing  its  own  ciphertext — 
then  the  disruptor  could  avoid  leaving  witness  bits  by 
flipping  only  1  bits  to  0  in  the  victim’s  slot.  To  make 
all  cleartext  bits  unpredictable,  clients  apply  a  crypto¬ 
graphic  padding  scheme  analogous  to  OAEP  [7].  The 
client  picks  a  random  seed  r,  generates  a  one-time  pad 
s  =  PRNGjr},  XORs  it  with  the  original  message  m, 
and  transmits  r||TO  ©  s  in  the  client’s  message  slot.  Since 
clients  submit  their  ciphertexts  before  the  servers  compute 
theirs,  and  the  commitment  phase  in  Algorithm  2  prevents 
dishonest  servers  from  learning  honest  servers’  cipher- 
texts  before  computing  their  own,  any  disruptive  bit-flip 
has  a  1/2  chance  of  producing  a  witness  bit. 

The  second  challenge  is  enabling  the  victim  to  trans¬ 
mit  its  accusation:  if  it  did  so  via  DC-nets,  the  disruptor 
could  simply  corrupt  that  transmission  as  well.  To  avoid 
this  catch-22,  Dissent  falls  back  on  the  less  efficient  but 
disruption-resistant  verifiable  shuffle  it  uses  for  schedul¬ 
ing.  Each  client’s  DC-net  message  slot  includes  a  fc-bit 
shuffle  request  field,  which  the  client  normally  sets  to  0. 
When  a  disruption  victim  identifies  a  witness  bit,  it  sets 
its  shuffle  request  field  in  subsequent  rounds  to  a  A: -bit 
random  value.  Any  nonzero  value  signals  the  servers  to 
start  an  accusation  shuffle,  in  which  the  victim  transmits 
its  signed  accusation.  The  disruptor  may  try  to  squash  the 
shuffle  request,  but  succeeds  with  at  most  1  —  ( | )  ^  chance, 
and  the  victim  simply  retries  until  it  succeeds. 

The  final  challenge  is  tracing  the  actual  disruptor.  An 
accusation  consists  of  the  round  number  in  which  the  dis- 
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mption  occurred,  a  slot  index  7r(i},  and  the  index  A:  of  a 
bit  the  disruptor  flipped  from  0  to  1  in  this  slot,  all  signed 
by  the  slot  owner’s  pseudonym  key,  On  receiving 

an  accusation,  the  servers  verify  its  signature,  and  check 
that  the  indicated  bit  was  indeed  output  as  1 .  The  servers 
then  recompute  and  exchange  all  the  individual  PRNG 
bits  that  the  clients  and  servers  should  have  XORed  to¬ 
gether  to  compute  their  ciphertexts:  Cij[k]  in  Algorithm  1 
and  Sij  [/c]  in  Algorithm  2.  Each  server  independently  at¬ 
tempts  to  And  a  mismatch,  where:  (a)  a  server  did  not 
transmit  the  full  set  of  client  ciphertext  bits;  (b)  the  accu¬ 
mulation  of  transmitted  bits  do  not  match  what  the  server 
sent  out  earlier:  Sj[k]  ^  {®^(zlS^j[k])®{^^^^,  Ci[k])-or 
(c)  the  client’s  ciphertext  bit  does  not  match  the  accumu¬ 
lation  across  servers:  0^  Sij[k]  ^  Ci[k],  for  some  client 
i.  The  first  two  cases  trivially  expose  a  server  as  dishon¬ 
est.  In  the  Anal  case,  each  server  requests  from  client  i  a 
rebuttal  on  why  the  set  of  server  bits,  [fc],  are  incorrect, 
namely  which  server  equivocated.  An  honest  client  can 
respond  with  the  malicious  server’s  identity,  their  shared 
secret,  and  proof  of  this  shared  secret. 

3.10  Scheduling  via  Verifiable  Shuffles 

Dissent  uses  verifiable  shuffles  [1 1, 32, 44]  both  to  sched¬ 
ule  and  distribute  pseudonym  keys  for  subsequent  DC- 
nets  rounds,  and  for  transmitting  accusations  to  servers. 
Clients  submit  messages  (or  keys  to  be  anonymized)  to 
the  shuffle  protocol,  and  the  shuffle  outputs  a  random  per¬ 
mutation  of  these  messages  (or  keys),  such  that  no  subset 
of  clients  or  servers  knows  the  permutation.  Dissent  de¬ 
pends  minimally  on  the  shuffle’s  implementation  details, 
so  many  shuffle  algorithms  should  be  usable. 

Dissent  uses  Neff’s  verifiable  shuffle  [44]  to  cre¬ 
ate  verifiable  secret  permutations,  and  Chaum-Pedersen 
proofs  [15]  for  verifiable  decryptions.  To  shuffle,  each 
client  submits  an  ElGamal-encrypted  group  element.  In 
a  general  message  shuffle,  clients  embed  their  messages 
within  a  group  element,  encrypt  it  with  a  combination  of 
all  server  keys,  then  transmit  it  to  first  server,  who  shuffles 
the  input  and  removes  a  layer  of  encryption.  Each  server 
shuffles  and  decrypts  in  turn,  until  the  last  server  reveals 
the  cleartexts  and  distributes  them  to  all  clients. 

The  design  supports  both  general  message  shuffles  and 
more  efficient  key  shuffles.  Since  Neff’s  algorithm  shuf¬ 
fles  ElGamal  ciphertexts,  general  messages  must  be  em¬ 
bedded  within  group  elements.  The  entries  of  a  key  shuf¬ 
fle  are  already  group  elements,  however,  thus  requiring  no 
message  embedding.  Key  shuffles  also  permit  the  use  of 
more  computationally  efficient  groups  that  are  suitable  for 
keys  but  not  for  message  embedding. 


3.11  Limitations 

This  section  discusses  a  few  of  Dissent’s  shortcomings 
and  possible  ways  to  address  them  in  future  work. 

Large  networks  with  many  groups  Our  evaluations 
(Section  5)  demonstrate  that  a  single  Dissent  network  can 
accommodate  over  5,000  clients.  To  be  broadly  usable  at 
Internet  scale.  Dissent  must  scale  to  much  larger  network 
sizes,  of  hundreds  of  thousands  of  nodes  or  more.  One 
way  to  serve  very  large  networks  would  be  to  adopt  a  tech¬ 
nique  introduced  by  Herbivore  [35]:  break  the  overall  net¬ 
work  into  smaller  parallel  Dissent  groups — with  tens  of 
servers  and  thousands  of  clients  each.  A  secure  join  pro¬ 
tocol,  as  in  Herbivore,  could  protect  a  single  session  from 
being  overrun  with  Sybil  identities. 

Intersection  attacks  Dissent’s  traffic  analysis  resis¬ 
tance  does  not  protect  against  membership  intersection 
attacks,  where  an  adversary  correlates  linkable  anony¬ 
mous  transmissions  to  changes  in  clients’  online  status.  If 
an  anonymous  blogger  posts  a  series  of  messages,  each 
signed  by  the  same  pseudonym  but  posted  in  different 
rounds,  and  the  adversary  sees  that  only  Alice  was  online 
in  all  of  those  rounds  (though  many  other  group  members 
were  present  in  some  rounds),  the  adversary  might  pin¬ 
point  Alice  as  the  blogger.  There  is  no  perfect  defense 
against  intersection  attacks  when  online  status  changes 
over  time  [39].  Dissent  users  could  gain  some  protection 
against  the  intersection  attack  by  avoiding  linkable  anony¬ 
mous  transmissions  (e.g.,  the  use  of  pseudonyms).  Alter¬ 
natively,  users  could  adopt  a  “buddy  system,’’  transmitting 
linkable  cleartexts  only  when  all  of  a  fixed  set  of  “bud¬ 
dies”  are  also  online.  With  certain  caveats,  this  discipline 
ensures  that  a  user’s  anonymity  set  includes  at  least  his 
honest  buddies,  at  the  availability  cost  of  making  the  user 
unable  to  transmit  (safely)  when  any  buddy  is  offline. 

Handling  server  failure  Dissent  addresses  network 
churn  only  among  clients:  if  a  server  goes  offline,  the  pro¬ 
tocol  halts  completely  until  all  servers  are  available  again 
or  the  group  is  administratively  re-formed  to  exclude  the 
failed  server  (which  currently  amounts  to  creating  a  new 
group).  We  expect  that  Byzantine  fault-tolerance  tech¬ 
niques  [12]  could  be  adapted  to  mask  benign  or  malicious 
server  failures,  at  a  cost  of  imposing  a  stronger  security 
assumption  on  the  servers.  In  a  BET  group  designed  to  tol¬ 
erate  /  concurrent  failures,  for  example,  client  anonymity 
would  likely  depend  on  at  least  f  +  1  servers  being  honest, 
rather  than  just  one.  A  malicious  group  leader  could  form 
a  live  “view”  deliberately  excluding  up  to  /  honest  and 
online  servers,  replacing  them  with  /  dishonest  servers 
who  appear  live  and  well-behaved  but  privately  collude  in 
attempt  to  de-anonymize  clients. 


Group  management  and  server  selection  As  dis¬ 
cussed  in  Section  3.2,  Dissent  groups  currently  contains 
a  static  list  of  clients  and  servers;  allowing  more  dy¬ 
namic  group  administration  while  maintaining  security  re¬ 
mains  an  important  challenge.  In  a  public  Dissent  deploy¬ 
ment  with  hundreds  of  servers  and  thousands  of  paral¬ 
lel  groups,  users  would  benefit  especially  from  automatic 
server  selection.  Since  the  user  must  trust  at  least  one  of 
the  servers,  a  server  selection  algorithm  might  have  to 
consider  which  servers  user  trusts,  how  close  the  user  is 
to  which  servers,  a  server’s  reliability,  and  other  security 
and  performance  factors.  Dissent’s  server  selection  prob¬ 
lem  is  likely  analogous  to  the  path  selection  problem  in 
Tor  [6,28],  and  might  build  on  prior  work  on  this  topic. 

Mobile  devices  In  the  United  States,  consumers  now 
use  mobile  phones  more  for  Internet  browsing  and  non¬ 
voice  data  transfer  than  for  making  phone  calls  [61].  As 
everyday  computing  shifts  to  mobile  devices,  an  ongo¬ 
ing  challenge  is  to  offer  users  the  same  privacy  protec¬ 
tions  on  phones  as  they  would  have  on  desktop  comput¬ 
ers  [8,33,34].  We  have  yet  to  deploy  or  test  Dissent  on  mo¬ 
bile  devices,  but  expect  Dissent’s  computation  and  com¬ 
munication  optimizations  to  be  useful  in  this  context. 

Formal  security  analysis  While  Dissent  is  based  on 
techniques  with  formal  security  proofs  [14, 15,44],  a  full 
formal  analysis  of  Dissent  remains  for  future  work. 

4  Implementation 

This  section  describes  the  current  Dissent  prototype  and 
how  we  have  applied  it  to  two  anonymous  communica¬ 
tion  use  cases:  wide-area  group  messaging  and  local-area 
anonymous  Web  browsing. 

4.1  Prototype  Overview 

We  have  implemented  Dissent  in  C-n-  with  the  Qt  frame¬ 
work  and  the  CryptoPP  cryptography  library.  The  proto¬ 
type  implements  the  complete  Dissent  anonymity  proto¬ 
col  along  with  the  accountability  sub-protocols  described 
in  Section  3.9.  The  system  assumes  the  existence  of  a  cer¬ 
tificate  authority  (or  other  entity)  that  manages  the  long¬ 
term  public  keys  of  all  servers  and  clients.  The  prototype 
also  assumes  that  participants  have  used  an  outside  chan¬ 
nel  to  agree  upon  a  common  set  of  servers.  Source  code 
may  be  found  at  the  Dissent  project  home  page.' 

User  applications  interact  with  a  node  running  our  Dis¬ 
sent  prototype  using  HTTP  API  calls  or  a  SOCKS  proxy 
interface.  The  HTTP  API  allows  clients  to  post  raw  mes¬ 
sages  (byte-strings)  directly  into  the  protocol  session.  The 
prototype’s  SOCKS  v5  proxy  allows  users  to  tunnel  TCP 
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and  UDP  traffic  flows  transparently  through  the  Dissent 
protocol  session.  One  or  more  nodes  in  the  Dissent  net¬ 
work  serve  as  SOCKS  entry  nodes,  which  listen  for  in¬ 
coming  SOCKS  proxy  requests  from  user  applications 
(e.g.,  Skype  or  Firefox).  The  entry  node  accepts  SOCKSi- 
fied  traffic  flow  from  the  user  application,  assigns  the  flow 
a  random  identifier  (to  allow  a  receiving  node  to  distin¬ 
guish  between  many  flows),  adds  destination  IP  and  port 
headers  to  the  flow,  and  sends  it  into  the  active  Dissent 
protocol  round.  A  single  SOCKS  exit  node  (who  is  a  non- 
anonymous  protocol  participant)  reads  the  tunneled  traf¬ 
fic  from  the  Dissent  protocol  round,  forwards  it  over  the 
public  network  to  the  destination  server,  and  sends  the  re¬ 
sponse  back  through  the  Dissent  session. 

4.2  Anonymous  Microblogging  Application 

Dissent’s  decentralized  architecture  and  trust  model  make 
it  potentially  attractive  as  a  substitute  for  commercial  mi¬ 
croblogs  in  high-risk  anonymous  communication  scenar¬ 
ios.  Since  Dissent  relies  on  no  single  trusted  party,  we  ex¬ 
pect  it  to  be  much  more  challenging  even  for  a  power¬ 
ful  adversary — such  as  an  authoritarian  government  or  its 
state-controlled  ISP — to  identify  an  anonymous  blogger 
without  compromising  all  participating  Dissent  servers. 

In  our  evaluation  section,  we  present  performance  re¬ 
sults  for  a  prototype  microblogging  system  running  on 
PlanetLab  with  up  to  2,000  nodes  and  DeterLab  with 
up  to  5,000  nodes.  A  simple  chat-like  Web  interface  al¬ 
lows  users  to  post  short  messages  into  an  Dissent  proto¬ 
col  session  using  our  HTTP  API.  Our  results  suggest  Dis¬ 
sent  could  form  a  practical  platform  for  Internet- sc  ale  mi¬ 
croblogging  in  situations  requiring  stronger  security  prop¬ 
erties  than  the  current  commercial  platforms  offer. 

4.3  Local-Area  Web  Browsing 

When  deployed  in  a  local-area  network.  Dissent 
can  provide  interactive  communication  with  local-area 
anonymity:  requests  are  anonymous  among  a  local  set  of 
users.  To  demonstrate  this  use  of  Dissent,  we  have  de¬ 
veloped  WiNoN,  a  system  that  uses  virtual  machines  to 
isolate  a  user’s  identifiable  OS  environment  from  their 
anonymous  browsing  environment,  an  important  issue 
given  that  browser  signatures  have  a  reasonable  chance 
of  uniquely  identifying  a  user  [27]. 

In  WiNoN,  depicted  in  Figure  5,  the  Dissent  client  soft¬ 
ware  runs  on  the  host  OS  with  network  traffic  from  the 
WiNoN  VM  tunneled  through  the  Dissent  SOCKS  proxy. 
Since  applications  in  the  WiNoN  VM  have  no  access  to 
the  network  interface  or  to  the  user’s  non-anonymous  stor¬ 
age,  they  are  unable  to  learn  the  user’s  long-term  identity 
(unless  the  user  inadvertently  enters  some  identifiable  in¬ 
formation  into  the  WiNoN  VM). 
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Figure  5:  WiNoN  system  diagram.  Traffic  from  the  anony¬ 
mous  VM  flows  through  an  Dissent  tunnel  to  an  exit  node. 
The  exit  node  reads  trafflc  from  the  tunnel  and  forwards  it 
onto  the  Internet  on  behalf  of  the  WiNoN  client. 


Figure  6:  A  CDF  plot  demonstrating  the  time  for  a  mes¬ 
sage  exchange  to  complete  when  using  four  message  win¬ 
dow  policies. 

we  used  PlanetLab  nodes  on  the  public  Internet  to  offer 
a  more  realistic  test  of  Dissent’s  ability  to  handle  client 
delays  and  churn.  For  our  evaluations  on  the  public  In¬ 
ternet,  we  used  eight  server  machines — one  located  at  our 
university  and  seven  at  EC2  sites — located  at  unique  loca¬ 
tions  on  four  different  continents,  and  we  used  the  entire 
set  of  available  PlanetLab  nodes  as  clients.  We  indicate 
the  exact  number  of  PlanetLab  clients  where  applicable. 


On  simulated  WiFi  networks  with  tens  of  nodes  and 
typical  bandwidth  and  delay  parameters,  we  And  the 
WiNoN  anonymization  network  fast  enough  for  browsing 
the  Internet  and  streaming  videos.  Prior  work  uses  virtual 
machines  to  isolate  network  environments  [41]  and  tunnel 
trafflc  through  Tor  [55].  No  previous  system  to  our  knowl¬ 
edge,  however,  enables  a  user  to  run  Flash  movies,  Skype, 
and  other  untrusted  applications  safely  and  anonymously. 

5  Evaluation 

This  section  first  examines  Dissent’s  ability  to  handle  un¬ 
reliable  client  nodes.  Next  we  evaluate  Dissent’s  perfor¬ 
mance  and  scalability  in  instant-messaging  and  data  shar¬ 
ing  scenarios  with  varying  numbers  of  clients  and  servers. 
We  then  explore  the  costs  of  different  protocol  stages:  the 
initial  key  shuffle,  a  DC-net  exchange,  and  finally  the  ac¬ 
cusation  process.  Finally,  we  evaluate  the  performance  of 
Dissent  applied  to  the  WiNoN  Internet  browsing  applica¬ 
tion  described  in  section  4.3. 

In  our  evaluations,  we  used  the  Emulab  [29],  Deter- 
Lab  [23],  and  PlanetLab  [16]  testbeds,  and  nodes  from 
Amazon’s  EC2  service.  Emulab  and  DeterLab  offer  con¬ 
trolled,  repeatable  conditions  on  isolated  networks,  while 


5.1  Slow  and  Unreliable  Clients 

On  public  networks,  distributed  systems  must  cope  with 
slow  and  unreliable  machines  [47].  Dissent’s  servers  pre¬ 
vent  slow  nodes  from  impeding  the  protocol’s  overall 
progress  by  imposing  a  ciphertext  submission  window. 
Once  the  client  submission  time  window  has  closed, 
servers  continue  executing  the  protocol  even  if  every 
client  has  not  submitted  a  ciphertext.  Larger  windows  po¬ 
tentially  allow  more  clients  to  participate  in  each  message 
exchange,  but  increase  messaging  latency.  Smaller  win¬ 
dows  size  reduce  latency  of  exchanges  but  might  prevent 
slower  clients  from  participating. 

To  help  us  select  an  effective  window  closure  policy  for 
our  evaluations  on  PlanetLab,  we  collected  a  data  trace 
from  a  Dissent  deployment  with  over  500  clients  running 
on  PlanetLab  nodes  and  eight  servers  running  on  EC2,  us¬ 
ing  a  static  window  size  of  120  seconds.  The  exact  number 
of  clients  varied  over  the  course  of  the  24-hour  evaluation 
period.  We  used  the  data  from  this  PlanetLab  experiment 
to  test  a  variety  of  window  closure  policies. 

To  ensure  that  most  clients  are  able  to  participate  in 
each  message  exchange,  we  do  not  close  the  submission 
window  until  at  least  95%  have  submitted  messages.  Once 
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95%  of  clients  submit  messages,  we  multiply  the  time 
elapsed  by  a  constant  factor  to  determine  window  time. 

The  fraction  of  clients  who  missed  the  submission  win¬ 
dow  decreased  as  this  multiplicative  constant  increased: 

1.1  x:  2.3%,  1.2 x:  1.5%,  and  2x:  0.5%.  The  data  in  Fig¬ 
ure  6  demonstrate  that  the  client  submission  time  is  not 
very  sensitive  to  multiplicative  constant  used.  For  the  rest 
of  the  evaluation,  we  chose  the  1.1  x  policy,  since  there 
was  not  significant  variation  among  the  three. 

Regardless  of  the  specific  window  closure  policy  cho¬ 
sen,  Figure  6  demonstrates  the  importance  of  insulating 
the  group’s  progress  from  that  of  its  slowest  clients  in 
an  unpredictable  environment  like  PlanetLab.  In  the  base¬ 
line  case  where  the  servers  wait  until  all  clients  submit 
or  a  120- second  hard  deadline  is  reached,  50%  of  DC- 
net  rounds  are  delayed  by  “stragglers”  by  an  order  of 
magnitude  or  more  compared  with  early-cutoff  policies, 
and  15%  of  rounds  are  delayed  until  the  120-second  hard 
deadline  versus  almost  none  with  early  cutoff  policies. 

5.2  Wide-Area  Applications 

To  evaluate  Dissent’s  usability  in  wide-area  microblog¬ 
ging  or  data  sharing  scenarios,  as  described  in  Section  4.2, 
we  evaluated  the  protocol  on  both  DeterLab  [23]  and 
PlanetLab  [16].  On  DeterLab,  which  offered  controlled 
test  conditions  and  greater  hardware  resources,  we  eval¬ 
uated  both  a  microblog  and  data  sharing  like  behavior;  we 
evaluated  only  the  microblog  scenario  on  PlanetLab. 

To  simulate  a  plausible  traffic  load  in  the  microblog 
scenario,  a  random  1%  of  all  clients  submit  128-byte  mes¬ 
sages  during  any  particular  round.  In  the  data  sharing  sce¬ 
nario,  one  client  transmits  a  128KB  message  per  round. 

Due  to  time  and  resource  limitations,  the  DeterLab 
evaluation  used  two  system  topologies:  32  servers  with  10 
client  machines  per  server,  and  24  servers  with  12  client 
machines  per  server,  for  a  total  of  320  and  288  client  ma¬ 
chines  respectively.  To  simulate  a  larger  number  of  Dis¬ 
sent  client  participants  than  we  had  physical  testbed  ma¬ 
chines  for,  we  ran  up  to  16  Dissent  client  processes  on 
each  client  machine,  for  up  to  5120  client  processes. 

In  the  testbed  topology,  servers  shared  a  common  100 
Mbps  network  with  10  ms  latency,  while  clients  shared 
a  100  Mbps  uplink  with  50  ms  latency  to  their  common 
server.  We  intended  the  servers  to  share  a  1000  Mbps  net¬ 
work,  but  the  testbed  did  not  support  this  configuration. 

For  the  PlanetLab  tests,  we  deployed  17  servers:  16  on 
EC2  using  US  East  servers  and  one  control  server  located 
at  Yale  University.  The  latency  between  Yale  and  EC2  was 
approximately  14  ms  round  trip.  This  clustered  setup  is  in¬ 
tended  to  represent  a  deployment  scenario  in  which  mul¬ 
tiple  organizations  offer  independently-managed  Dissent 
servers  physically  co-located  in  the  same  or  geograph- 
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.---X---.  128K  message  -  Client  submission  (DeterLab) 

I — I — I  1%  submit  -  Server  processing  (PlanetLab) 

1%  submit  -  Client  submission  (PlanetLab) 
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Figure  7:  Time  per  round  in  microblog  (1%  submit)  and 
data  sharing  scenarios,  for  varying  number  of  clients. 

ically  nearby  data  centers,  facilitating  high-bandwidth 
and  low-latency  communication  among  the  servers  while 
keeping  their  management  decentralized  for  security. 

Figure  7  shows  the  system’s  scalability  with  client  load 
by  varying  the  number  of  clients  relying  on  a  static  set  of 
32  servers.  Figure  8  in  turn  varies  the  number  of  servers 
while  maintaining  a  static  set  of  640  clients.  At  smaller 
group  sizes,  additional  servers  do  not  benefit  performance. 
As  demands  on  the  servers  scale,  however,  their  utility 
becomes  more  apparent,  especially  in  the  128K  message 
scenario.  Performance  appears  to  be  dominated  by  client 
delays,  namely  the  time  between  clients  receiving  the 
previous  round’s  cleartext  and  the  servers  receiving  the 
current  round’s  ciphertext  message.  However,  in  compar¬ 
ing  the  PlanetLab  evaluation  to  the  DeterLab  evaluation 
and  server  size  of  1,  we  can  ascertain  that  latency  be¬ 
tween  servers  tends  to  dominate  delays  in  that  environ¬ 
ment,  though  computational  load  is  not  negligible. 

The  prototype  shows  greatest  usability  for  group  sizes 
up  to  1,000;  thereafter  delays  become  longer  than  1  sec¬ 
ond  in  the  microblogging  scenario.  At  best,  delays  were 
on  the  order  of  500  to  600  ms  for  32  to  256  clients.  In 
the  static  client  network,  varying  server  count,  showed 
time  increases  on  server-related  aspects  of  the  protocol 
but  reduced  time  on  client-related  aspects.  We  therefore 
expect  that  with  greater  demand — either  in  terms  of  nodes 
or  bandwidth — client-related  costs  are  likely  to  dominate. 

In  comparing  the  microblogging  and  128K  message 
scenarios,  the  graphs  suggest  that  bandwidth  tends  to 
dominate  for  larger  messages  and  latency  for  smaller 
messages.  Most  importantly,  the  evaluations  suggest  that 
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I — I — I  1 28K  message  -  Server  processing 
U--X— j  128K  message  -  Client  submission 
I — I — I  1%  submit  -  Server  processing 
j  1%  submit  -  Client  submission 

Figure  8:  Time  per  round  in  microblog  (1%  submit)  and 
data  sharing  scenarios,  for  varying  number  of  servers  sup¬ 
porting  640  clients. 

Dissent  can  support  delay-sensitive  applications  like  mi¬ 
croblogs  and  instant  messaging. 

5.3  Full  System  Evaluation 

While  the  previous  experiments  focused  on  measuring 
DC-nets  rounds,  the  primary  focus  of  this  paper,  we  now 
explore  time  durations  in  a  single  full  execution  of  the 
entire  Dissent  protocol:  key  shuffle,  a  single  DC-net  ex¬ 
change,  accusation  shuffle,  and  accusation  tracing.  Our 
results  shown  in  Figure  9  used  the  same  DeterLab  con¬ 
figuration  consisting  of  24  servers  with  12  clients  each 
configuration  as  described  in  the  previous  section.  In  con¬ 
trast  to  verifiable  mix-nets,  the  Dissent  protocol’s  DC-nets 
round  is  extremely  efficient,  accounting  for  a  negligible 
portion  of  total  time  in  large  groups. 

The  time  difference  between  accusation  and  key  shuf¬ 
fles  illustrate  the  performance  benefits  of  the  key  shuffle 
discussed  in  Section  3.10.  In  small  groups  the  accusation 
shuffle  is  reasonably  fast,  but  in  larger  groups  its  cost  in¬ 
creases  quickly,  to  over  an  hour  for  1,000-client  groups. 

5.4  Web  Browsing:  Dissent  and  Tor 

To  explore  the  practicality  of  Dissent  for  local-area 
anonymity  as  described  in  section  4.3,  we  deployed  a 
smaller-scale  Dissent  network  of  5  servers  and  24  clients 
on  the  Emulab  [29]  network  testbed.  The  testbed’s  exper¬ 
imental  network  topology  approximated  the  characteris¬ 
tics  of  a  small  WiFi  network:  each  node  was  connected 
to  a  central  switch  via  a  24  Mbps  link  with  10  ms  of  la¬ 
tency.  One  of  the  servers  acted  as  a  gateway  connecting 
the  private  test  network  to  the  public  Internet. 

In  this  environment,  we  ran  an  automated  HTTP 
browser  on  one  of  the  client  nodes  to  download  the  in- 


Number  of  clients 

Figure  9:  Time  elapsed  during  a  whole  protocol  run  for 
varying  client  sizes,  24  servers,  and  128  byte  messages. 

dex  pages  from  each  site  on  the  Alexa  “Top  100”  Web 
sites  [3]  from  the  real  public  Web  server.  For  each  in¬ 
dex  page,  the  client  requested  the  HTML  page  and  then 
recursively  and  concurrently  requested  dependent  assets 
(images,  CSS,  JS,  etc.).  Although  we  used  an  automated 
HTTP  browser  for  these  trials.  Dissent  supports  standard 
Web  browsers  as  well. 

We  used  four  different  network  configurations  to  test 
Dissent’s  performance  under  four  deployment  scenarios. 
In  the  first  scenario,  no  anonymity,  the  gateway  connects 
directly  to  the  public  Internet.  The  second  scenario,  Tor 
alone,  shows  the  performance  of  state-of-the-art  wide- 
area  anonymous  Internet  access.  We  emphasize  that  we 
compare  with  Tor  only  to  provide  a  general  reference 
point  for  gauging  Dissent’s  usability:  this  is  by  no  means 
an  “apples-to-apples”  comparison  since  the  functionality, 
scale,  security  properties,  and  network  conditions  of  the 
two  systems  under  test  are  incomparable  in  myriad  ways. 

The  third  test  scenario,  a  local-area  deployment  of  Dis¬ 
sent,  is  intended  to  test  whether  Dissent  is  fast  enough 
for  interactive  browsing  on  local-area  networks.  The 
fourth  scenario,  a  serial  composition  of  Dissent  and  Tor, 
considers  the  performance  of  a  configuration  offering 
“best  of  both  worlds”  security,  where  we  compose  a 
local-area  Dissent  network  with  the  public  Tor  network. 
This  configuration  offers  users  Tor’s  wide-area  anonymity 
against  limited-strength  adversaries,  combined  with  Dis¬ 
sent’s  local-area  security  against  adversaries  who  might 
use  traffic  analysis  to  de-anonymize  Tor  circuits. 

The  results  in  Figure  10  indicate  that  anonymous  web 
browsing  under  the  local-area  deployment  of  Dissent  we 
tested  performs  comparably  to  Tor,  suggesting  that  users 
are  likely  to  find  some  Dissent  configurations  similarly 
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Figure  10:  Download  times  for  the  Alexa  “Top  100”  home 
pages  in  which  nodes  access  the  Internet  over  an  Dissent 
network  running  on  an  Emulab-simulated  wireless  LAN, 
over  the  public  Tor  network,  and  over  a  composition  of 
wLAN  Dissent  and  Tor. 


Figure  1 1 :  CDF  of  download  times  presented  in  Figure  10. 

usable  under  appropriate  network  conditions.  On  average, 
downloading  1MB  of  Web  content  took  10  seconds  with 
no  anonymization,  it  took  40  seconds  through  Tor,  45  sec¬ 
onds  with  Dissent,  and  55  seconds  with  Dissent  and  Tor 
together.  Comparing  Dissent-tTor  with  Tor  alone,  this  data 
suggests  that  a  user  willing  to  tolerate  a  35%  slowdown 
could  retain  Tor’s  wide-area  benefits  while  gaining  traffic 
analysis  resistant  anonymity  in  the  user’s  local  area. 

Figure  1 1  shows  a  CDF  of  page  download  times,  show¬ 
ing  that  a  client  using  Tor  downloads  the  first  50%  of  Web 
pages  in  15  seconds,  while  a  client  using  Dissent-tTor 
downloads  50%  of  Web  pages  in  just  under  20  seconds. 
We  expect  that  many  users,  especially  those  with  strong 
security  requirements,  might  find  a  few  extra  seconds  per 
Web  page  a  reasonable  price  for  local-area  security. 


6  Conclusion 

This  paper  has  made  the  case  that  by  delegating  col¬ 
lective  trust  to  a  decentralized  group  of  servers,  strong 
anonymity  techniques  offering  traffic  analysis  resisfance 
may  be  adapted  and  scaled  to  offer  anonymity  in  groups  of 
thousands  of  nodes,  two  orders  of  magnitude  larger  than 
previous  systems  offering  strong  anonymity.  Through  its 
novel  client/server  DC-nets  model.  Dissent  is  able  to  ac¬ 
commodate  anonymity  set  sizes  of  up  to  5,000  members, 
while  maintaining  end-to-end  latency  low  enough  to  en¬ 
able  wide-area  interactive  messaging.  In  local-area  set¬ 
tings,  Dissent  is  fast  enough  to  handle  interactive  Web 
browsing  while  still  offering  users  strong  local  anonymity 
guarantees.  Although  Dissent  represents  a  step  towards 
strong  anonymous  communication  at  large  Internet  scales, 
many  challenges  remain  for  future  work,  such  as  further 
scalability  and  robustness  improvements  and  protection 
against  long-term  intersection  attacks. 
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